home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 8282 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.0 KB
  1. Path: dawn.mmm.com!news
  2. From: kjhopps@mmm.com (Kevin J Hopps)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Exceptions and operator new. Help
  5. Date: 16 Feb 1996 14:31:02 GMT
  6. Organization: 3M - St. Paul, MN  55144-1000 US
  7. Message-ID: <4g24f6$54n@dawn.mmm.com>
  8. References: <4fu14a$2vg@news.tamu.edu>
  9. Reply-To: kjhopps@mmm.com
  10. X-Newsreader: TIN [version 1.2 PL2]
  11.  
  12. Pradeep K Tapadiya (tpradeep@cs.tamu.edu) wrote:
  13. > According to the C++ specs, a new will throw a xalloc exception
  14. > if memory allocation fails. The return value from new need not be
  15. > NULL. In addition, the constructor can throw a different exception
  16. > as defined by you, the programmer. This means, each time, I do a
  17. > new, I have to do something like 
  18.  
  19. >    myObject* p = NULL;
  20.  
  21. >    try {
  22. >      myObject* p = new myObject;
  23. >    }
  24. >    catch (xlloc e) {
  25. >      // do not delete p here since it was never allocated
  26. >      ...
  27. >    }
  28. >    catch (myException& e) {
  29. >       delete p;
  30. >     ...
  31.  
  32. This is not the case.  If the constructor for myObject throws an exception,
  33. the memory allocated by new will be released for you.
  34.  
  35. > Moreover, if myObject's destructor has to do some
  36. > memroy cleanup, for example,
  37.  
  38. > myObject::~myObject ()
  39. > {
  40. >    delete [] m_pVarList;
  41. > }
  42.  
  43. > then, the constructor will probably has to do something like
  44.  
  45. > myObject::myObject ()
  46. > {
  47. >    try {
  48. >      m_pVarList = new char [10];
  49. >    }
  50. >    catch (xalloc e) {
  51. >      m_pVarList = NULL; // explicitly set it to NULL as destructor will
  52. >                         // try to delete a bogus pointer
  53. >      throw xalloc ();
  54. >    }
  55. > }
  56.  
  57. If the constructor for myObject throws an exception, the myObject is
  58. not fully constructed, so its destructor will not be called.  However,
  59. any fully constructed sub-objects of the myObject will be destroyed
  60. when an exception is thrown in the myObject constructor.
  61.  
  62. > Now, setnewHandler adds another variable to the model. As you cannot
  63. > rely on what third party library is doing, anytime you do a new on
  64. > your object, you will explictly have to do a setnewhandler to your handler.
  65.  
  66. Why will I have to do that?
  67.  
  68. > Though we have been programming in C++ for quite some time, this is
  69. > the first time our company is venturing out into the world of
  70. > exceptions. It now appears exceptions would make the development process
  71. > more complicated.
  72.  
  73. In some ways exceptions make the development process more complicated.
  74. In other ways they make it less complicated.  They are a different way
  75. of reporting errors.  IMHO, they offer greater potential for writing
  76. robust code, at the cost of some education on their use and pitfalls.
  77.  
  78. > Am I missing something in the way I am using exceptions?
  79.  
  80. Yes, but they're new to you.
  81.  
  82. > Am I abusing exception handling mechanism?
  83.  
  84. In the examples above, you're making it more difficult than it really is.
  85.  
  86. > How are you handling exceptions with new opeartor?
  87.  
  88. If you mean "what am I doing with out-of-memory conditions," I'm
  89. recovering the same way I always have.  Exceptions don't change
  90. what I do to handle the error, they only change how I find out
  91. about it.
  92.  
  93. If you mean "am I writing any special new handlers or extra
  94. try/catch blocks around constructors," the answer is no.  The
  95. difference is that I no longer check for new returning 0, and
  96. I remember that when I call new, it may not return at all, but
  97. throw an exception.
  98.  
  99. > How are you integrating your code with third party library/dll?
  100.  
  101. Yes.  The library, RogueWave Tools.h++, will throw exceptions.
  102. I find it refreshing to write code that does not explicitly check
  103. for errors.  But I do have to remember that exceptions can be thrown
  104. nearly any time, and write my code accordingly.  This is the hard
  105. part about using exceptions.
  106. --
  107. Kevin J. Hopps                  e-mail: kjhopps@mmm.com
  108. 3M Company                      phone:  (612) 737-4643
  109. 3M Center, Bldg. 235-2D-57      fax:    (612) 737-2700
  110. St. Paul, MN 55144-1000         Opinions are my own.  I don't speak for 3M.
  111.     But 3M speaks for me -- I did not write the following line:
  112.  
  113. Opinions expressed herein are my own and may not represent those of 3M.
  114.